In today's electronic world, businesses frequently make use of e-commerce and web-based on-line services to support business activities. These activities—which may take the form of anything from ordering an article of commerce (or service) to attempting to respond to business-initiated questions to provide business feedback—involve an interactive user journey in cyberspace. In real time, this journey necessitates keystroke entries, data selection actions for window pull-down options and mouse movements by the end-user on, typically, a HTML-generated page. From the end user's perspective, the journey may be viewed (at least to some extent) on a computer monitor or PDA screen.
U.S. Pat. No. 6,286,030—Wenig et at (and the corresponding European patent EP 1097428) describes a system and method for auditing network applications. More particularly, the system operates from the perspective of the server to capture transmissions during a user session between a client and the server. An auditor capture filter captures and stores each request from the client and each response by the server to each request in an auditor storage. An auditor analyzer may use the captured requests and the captured responses to visually recreate the user session to thereby analyze what transpired during the user session.
Unfortunately, with the nature of the communication path and also the nature of data entry, uncertainty frequently exists with respect to what information or instructions have been successfully communicated. For example, HTML-based pages and/or applications can leave doubts in the mind of the end user as to whether data entry has been successfully completed. In other words, when there's a connection hang-up and/or potentially the freezing of the screen at the end user's computer, at the point of re-boot the web browser generally cannot recover the precise state of entered data fields and/or otherwise the user is left bemused as to whether or not the last (or indeed any) data entry was successfully communicated and, for example, whether the client has actually placed and order.
Furthermore, from the perspective of the server and especially the business, when an on-line client interaction fails to finish at a reasonably projected, i.e. anticipated, point of business completion, existing systems generally fail to provide any rationale for the failure. For example, during on-line shopping, a user may suddenly and unexpectedly terminate an order process for a dress by leaving a web browser-based page (and even the entire website), notwithstanding that the user has potentially completed 99% of a transaction process. It may be, for example, that the client wanted to order a size “M” coat in red, but the pull down menu only listed the size “M” in colour ways blue and green (with red “out of stock” for size “M”). While the loss of one client at one time may not seem a catastrophe, the “aggregation of marginal gains” philosophy indicates that, statistically, singular events stack up and represent a real loss of business opportunities.
The aforementioned U.S. Pat. No. 6,286,030-Wenig patent established that data auditing could be achieved from the server-side only. The commercial implementation of the audit process has seen a data TAP placed behind a company file wall and in front of a server, i.e. on premise delivery of a service; this is time-consuming, expensive and leads to access and installation issues. A later refinement of this approach—see US20100042573—established that a web browser at the client could be provided with tag code/JavaScript configured to capture local client events, namely timing information, on-screen events, mouse activity and “click” actions, and then to communicate these captured events over a common communication path back to the proprietary server (behind the firewall). The data TAP then captures the incoming data and routes all this upcoming data to a capture box for audit analysis based on the client-side capture information. However this approach is complex, even more time-consuming than server-side alone, expensive to implement and leads to access and installation issues.
A slightly different approach sees tag code/JavaScript installed on a web browser at a client for a purely client-side capture approach, with the tag code both causing capturing of data related to activity on the client device and establishment of a distinct, secure (cloud-based) uplink reporting path independent of any client-server website traffic. In a similar way to the earlier, purely server-side system, a server supporting a website is located behind a firewall. A separate data aggregator—again behind a firewall—receives compressed uplink data over the secure dedicated path from the client computer running the web browser over the distinct uplink path. The website and the data aggregator are in linked communication with each other, with the link both allowing the aggregator to send report to the server and to send “spiders” to the website to retrieve data from the website that can be used to augment cloud-recovered data to provide fixed-format reports. This approach is embodied in the ClickTale® system (see US2011213822-Yavilevich) where an operative/team is/are able to view on-demand session playbacks from individual customers as captured and relayed by the java applet in the web browser on only the client side. This client-side system therefore captures the user journey and permits visual replay of those journeys in terms of on-screen mouse movements, and does not consider context or relevant background data. Although provided as software, the client-side system is inflexible since reports are fixed by an independent data aggregator owned, generally, by a third party not associated with the server and business web-site under investigation and are not subject to completely flexible definition by the end-user. In particular access to the underlying user journey data via a standard database language, such as SQL, is not available. More particularly, if a particular flagged event report is required, it would be necessary to embed and/or pre-install compatible, i.e. fully operational and debugged, code defining the event into both the e-commerce website and also the client's machine for execution by the client's web browser. Consequently, the nature of purely client-side capture of a user journey is not practical for effective hypothesis testing of many categories of website specific conversion barriers and user-interaction since continuous software changes to define events would lead to operational instability of the code used in the system. Rather, existing client-side capture is used to watch a video of the screen and mouse movements at a specific user, and is useful for testing end user experience. Conversely, the system is not good, i.e. poor, for identifying, technically diagnosing, quantifying and fixing the many categories of conversion barrier that prevent a final e-commerce transaction and which conversion barriers are specific to the web-site being audited. Conversion barriers include hard to replicate technical and performance problems of the specific website code and non-obvious problems with design or function of the user interface to the website.
To date, therefore, server-side capture with its associated costs of implementation has been the architecture and process by which web-site operation has been tested or assessed.